Greptile Summary

This PR updates Codex setup so the local plugin cache is installed during npx install. The main changes are:

• Adds .install-version writing to the bundled marketplace plugin root.
• Replaces the best-effort Codex marketplace upgrade with mandatory codex plugin add claude-mem@claude-mem-local.
• Updates non-TTY install contract tests for local marketplace registration and Codex cache installation.

Confidence Score: 5/5

The changes are focused on Codex setup behavior and are covered by targeted installer and runtime tests.

No issues were identified in the reviewed changes, and the described verification includes relevant non-interactive install, integration, typecheck, and build coverage.

_{Reviews (2): Last reviewed commit: "fix(codex): fail when plugin cache insta..." | Re-trigger Greptile}

@Retengart — #3095 overlaps this directly on the Codex path: same codex plugin add claude-mem@claude-mem-local install and the same removal of the Git-only plugin marketplace upgrade call. Same files too (CodexCliInstaller.ts + tests/install-non-tty.test.ts).

Confirmed our staged code didn't write .install-version at all; yours does, so that's a real fix I was missing. I've folded it into #3095 with one change: rather than seeding the marker into the marketplace plugin root before plugin add, #3095 writes it into the Codex cache dir after tree-sitter provisioning succeeds — so .install-version stays a truthful "runtime ready" signal and can't be copied optimistically for a cache whose provisioning later failed. Same end result for the runtime not yet set up false-positive you fixed, minus the failure window. Credited you in the PR.

#3095 is otherwise a superset on this path (it adds tree-sitter runtime provisioning). Rather than duplicate your work, I'd rather rebase onto #3066 or fold it in with co-authorship — your call. And I'd value your read on whether the marketplace-fallback resolution path also needs a marker, or if the cache-dir write covers the resolutions you were seeing.

Follow-up: I tested #3095 end-to-end after a fresh local install. The installer wrote .install-version only to the Codex plugin cache, not the marketplace root. A fresh Codex session did not emit the "runtime not yet set up" warning. I repeated the test with the Claude-cache marker temporarily removed to eliminate the fallback path; the warning remained absent. This confirms Codex supplies the installed plugin root to the hook environment, so the post-provision cache marker is sufficient. The marketplace fallback remains a separate defensive-resolution concern, but it does not block the native Codex install path tested here.

@rymalia Thanks for checking the Codex path end to end.

I am fine with folding #3066 into #3095 with credit/co-authorship if maintainers prefer #3095 as the superset path. The important parts from my side are:

• mandatory codex plugin add claude-mem@claude-mem-local failure propagation, so Codex setup cannot report success without an installed plugin cache;
• a truthful .install-version marker for the active Codex runtime root, so runtime not yet set up does not fire after successful provisioning.

Your cache-after-provisioning placement looks sufficient for the native Codex install path based on the fresh-session verification you posted. I would keep the marketplace-root marker as a defensive fallback concern, not a blocker for #3095.

I also prepared a main sync branch for #3095 here: https://github.com/Retengart/claude-mem/tree/pr3095-main-sync. It resolves the generated bundle conflict against current main and passes the targeted installer/parser/provider verification listed on #3095.